Apparatus and Systems For Measuring, Monitoring, Tracking and Simulating Enterprise Communications and Processes

ABSTRACT

The present invention comprises apparatus and systems for measuring, monitoring, tracking and simulating enterprise communications and processes. A central message repository or database is constructed, comprised of monitoring messages sent from process messaging systems. The database may then be accessed or queried as desired. A simulation tool assists in reviewing present and proposed processes and sub-processes before modifying existent systems or creating new systems.

The present invention relates to apparatus and systems for measuring,monitoring, tracking and simulating enterprise communications andprocesses. More particularly, the present invention relates tocomputer-based apparatus and systems for measuring, monitoring, trackingand simulating enterprise communications and processes in anasynchronous messaging environment.

BACKGROUND OF THE INVENTION

The activities of a business or enterprise can be grouped intoprocesses. Processes are business operations that are separated asdesired and usually occur across business units. For example, theprocess of taking orders and turning those orders into revenue may beknown as Order to Cash. The processes are comprised of sub-processes.For example, Order to Cash may be broken down into sub-processes such asReceive Order Inquiry, Provide Customer Quotation, Create CustomerOutline Agreement, Create Sales Order, Schedule Production, ManufactureProduct, Ship Product and Invoice Customer. Each sub-process may in turnbe broken down into discrete activities such as providing customernumber, entering that customer number, establishing pricing, determininga shipping date, etc.

The processes, sub-processes and activities operate, in part, bycommunicating information. For example, users may communicate throughemail. As another example, applications may communicate amongstthemselves through electronic data interchange (“EDI”) and other similarservices. Communication occurs horizontally, that is, among a process,sub-process and activities, as well as vertically, that is, betweenprocesses, sub-processes and activities.

Whether communications occur horizontally or vertically, amongapplications or users, communications are increasingly asynchronous ormessage based. That is, enterprise communications were formerlyprimarily synchronous, or connection oriented, in which a connection isestablished with prior coordination between communication end pointswith data then being transmitted over the connection. Enterprisecommunications are now increasingly asynchronous, or connectionless,transmitting data without prior coordination between communication endpoints, such as through “event based” communications which use messagesto move data instead of large files.

Asynchronous or message based communications permit loosely coupledconnections among and between systems because the end points do not haveto be prepared to receive the data when the message is transmitted.Loosely coupled connections permit more flexibility in assemblingprocesses. Flexibility in assembling processes is desirable in order topermit quick reaction to changing business conditions: if a particularsub-process or activity becomes unusable, the process can be reassembledwith a new sub-process or activity. For example, if a ManufactureProduct sub-process in the Order to Cash process at Widget Co.enterprise has a specific factory identified to manufacture the productand that factory has a fire or other disaster, making it unusable,Widget Co. will need to substitute a new factory. The ripple effect ofthat substitution among all of Widget Co.'s processes will change anynumber of parameters. A loosely coupled asynchronous connection amongWidget Co.'s processes provides rapid substitution of the new factoryfor the old because the end points of communication to the new factorydo not have to be predetermined before communications begin with the newfactory. Thus, the flexibility of the asynchronous message basedcommunication has permitted quick response to changing businessconditions.

Despite this flexibility, asynchronous or message based communicationsare problematic because of their loosely coupled nature. At any giventime, precise information on the progress of the processes is difficultto obtain—messages may be in transit and not instantly locatable. Forexample, if a customer calls for the status of an order, an enterprisecustomer service representative may be able to determine nothing morethan the fact that the order has been received and that the scheduledship date is X. There is often no ability to drill down into theinformation levels and review the status in more granularity, such asthe location of the good, the manufacturing status, etc., because theinformation required to review that status is in transit and unable tobe reviewed.

Of course, if the enterprise lacks the ability to access statusinformation, business partners of the enterprise will similarly lackthat ability. Thus, asynchronous communications may well increaseinefficiency among business partners as well.

The difficulty in reporting caused by message based architecture alsomakes it difficult for the enterprise to measure the efficiency of itsprocesses and their sub-process. Asynchronous messaging, with itsindeterminate transmission of information, means a company may not beable to easily measure the interval between each sub-process, e.g. thetime between Scheduling Production and the Manufacturing of a Product,and so easily measure the efficiency of their operations.

Finally, asynchronous messaging may provide an enterprise with anability to model and simulate processes. That is, since informationflows can be readily estimated through enterprises with asynchronousmessaging, and processes can be easily modeled from those flows,asynchronous messaging modeling provides the potential to model andsimulate processes. That potential is not realized with presenttechnology, however. Moreover, since as described above, enterpriseslack information on the processes they have implemented, the enterprisesare handicapped in their ability to modify those processes or plan newprocesses. A modeling and simulation tool, demonstrating processes,sub-processes and their activity or granular detail level would beextremely helpful, and would give the enterprise an opportunity toassemble, test, adjust, and simulate processes and their details.

Accordingly, it is an object of the present invention to provide a toolfor simulating message based architectures.

It is a further object of the present invention to provide monitoringcapabilities for enterprise processes.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a view of a process.

FIG. 2 shows a view of a process of a preferred embodiment.

FIG. 3 shows a screen of a preferred embodiment.

FIG. 4 shows a screen of a preferred embodiment.

FIG. 5 shows a screen of a preferred embodiment.

FIG. 6 shows a partial view of a preferred embodiment.

FIG. 7 shows a partial view of a preferred embodiment.

FIG. 8 shows a partial view of a preferred embodiment.

FIG. 9 shows a partial view of a preferred embodiment.

FIG. 10 shows a partial view of a preferred embodiment.

SUMMARY OF THE INVENTION

The present invention comprises apparatus and systems for measuring,monitoring, tracking and simulating enterprise communications andprocesses in an asynchronous messaging environment. For each originalmessage sent within a process, sub-process or activity, the preferredembodiments of the present invention send a separate monitoring messagecontaining data from the central message repository or database. Thisdata may include date, time, customer number, materials, quantity,amount, or other information, and be copied from the original message.Other embodiments may add data to the monitoring message aside from thatcontained in the original message.

This central message repository or database is comprised of informationpassing through the enterprise. In effect, the database provides acollection point or an “end point” for the asynchronous communications,and so allows the flexibility of asynchronous communications to becombined with the precision of synchronous communications. The databasecan be reviewed in any number of ways. For example, the database can bequeried to obtain specific information about that particular order orcustomer or could be examined across larger time spans such as days,weeks, or months, to gauge trends or performance. Of course, somepreferred embodiments may wish to create mirror databases or otherdatabases that can be used in various ways.

An enterprise's information flow can also be readily modeled andsimulated through creating new process, sub-process and/or activities oraltering existing process, sub-process or activities. The informationflows from those creations or alterations can be collected in one ormore databases and examined as desired.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 shows a sample process, Order to Cash, which is comprised ofvarious sub-processes: Receive Order Inquiry, Provide CustomerQuotation, Create Customer Outline Agreement, Create Sales Order,Schedule Production, Manufacture Product, Ship Product and InvoiceCustomer. The dashed line arrows connecting the sub-processes are thecommunication paths between the sub-processes. In the example shown inthe figure, the sub-processes actually communicate through a messagingbroker, such as an IBM MQSeries component, and the paths to and from thecomponent are identified identically. This messaging broker permitscertain sophisticated messaging uses, such as message queuing, some datatranslation, etc.

A messaging component is added to the messaging broker, through methodsknown in the art. This messaging component creates a “monitoring”message for each original message received by the broker. Thismonitoring message contains, in this embodiment, specific data generatedfrom the original messages passing between the sub-processes. Themonitoring message with its data is then sent from the messaging brokerto a central database repository or database (the terms “repository” or“database” are used interchangeably throughout.)

The messaging component may be, in some embodiments, or may not be, inother embodiments, provided by the messaging broker. For example, IBM'sMQSeries messaging broker provides a component that can be configured toperform a copying function for the messages it receives, and so createmonitoring messages for the messages it receives.

The specific data contained in the monitoring messages (in thisembodiment, this data is copied from the original messages passingbetween the sub-processes) is organized into data fields. Those datafields are path specific in this embodiment. For example, assume acustomer calls the enterprise (Widget Co.) whose process is shown inFIG. 1 and asks whether or not Widget Co. has a certain product (Type AWidgets.) That customer request will begin the Receive Order Inquirysub-process which will end with the generation of a Receive OrderInquiry message traveling to the Provide Customer Quotation sub-processthrough the messaging broker component. When the messaging brokerreceives the message on Path A, it will create a monitoring message, andsend the monitoring message to the central database repository, as shownin FIG. 2. In this embodiment, the data contained in the monitoringmessage is generated from the message on Path A. Other preferredembodiments may alter or add data to the monitoring messages aside fromthat contained in the original message.

The monitoring message contains, in this embodiment, specific datafields. (Of course, other embodiments may have different data fields.)Those data fields are:

FIELDS IDENTIFIERS PROCESS IDENTIFIER ProID, SUB-PROCESS IDENTIFIERSbProID, CUSTOMER NUMBER Custno, PART NUMBER Partno, QUANTITY Qty, DATEDate, TIME Time

The first field, the PROCESS IDENTIFIER field, provides the identifierfor the process, for example, the value “Order to Cash” because themonitoring message is being created within the Order to Cash process.The second field, the SUB-PROCESS IDENTIFIER field, provides theidentifier for the sub-process, for example, the value “Inquiry” becausethe monitoring message is being created within the Inquiry sub-process.This embodiment prepopulates these PROCESS IDENTIFIER and SUB-PROCESSIDENTIFIER fields, with the appropriate values.

The CUSTOMER NUMBER field is assigned to the particular customergenerating the inquiry. The PART NUMBER field is the identifier for theparticular part and the QUANTITY for the particular quantity. DATE andTIME are the data and time the message is generated. Other messagefields for other paths of this embodiment are shown in Table 1. Ofcourse, some, all or none of these fields may be present in otherembodiments, as well as other fields as desired. For example, one ormore ACTIVITY IDENTIFIER fields may be present in monitoring messages inother embodiments.

The monitoring message data populates one information flow ortransaction record (“transaction record.”) As monitoring messagesprogress through any given process and/or sub-process, the transactionrecord is updated. Once the monitoring messages complete the transactionrecord, all of the information needed to measure that transactionthrough the process is contained in one record in the central messagedatabase. (Of course, if the monitoring messages do not fully populatethe transaction record, e.g., the transaction is aborted in mid process,then these abandoned records may be made available as well with anindication that they were abandoned.)

The central message database can be reviewed in any number of ways, inorder to measure, monitor and track enterprise communications andprocesses, e.g., to provide information or generate reports. Using thecentral message database to provide information or generate reports “offloads” the information access or reporting processes from theapplications that generate messages initially, e.g., sub-processes suchas those seen in FIG. 1. This off loading relieves some of themonitoring pressure from the source applications so that, for example,any queries that might have been made to the source applications andinterfere with or slow down the operation of the source applications cannow be made through the central message database.

The information retrieved from the central message database may include,but is not limited to, information about any particular order orcustomer, information about process efficiency, “snapshot” or time sliceinformation, information across time spans such as days, weeks, ormonths, information to gauge trends or performance, etc. Also, in someembodiments, a “real-time” tool may be used to track the progress oftransaction records and/or processes and use distribution methods suchas broadcasting, WAP, etc. to provide the information to users. Forexample, if a process such as pipeline capacity for oil and natural gastransmissions is implemented and monitored through an embodiment of thepresent invention, the central message database will constantlybroadcast unused pipeline capacity, which information in turn can beused to sell, trade or barter that unused capacity. As another example,information about an enterprise's processes can be made available overan intranet, extranet, the Internet, etc. to business partners or otherentities. One example would be providing information to stock analystsso that they could track any particular enterprise's productivity orother areas of interest. Another example would be providing informationto actual or potential business partners to check production capacity,shipping capacity, or other areas of interest. In some embodiments, withregard to external entities, communication channels between the externalentities and the enterprise might well be established, so that centralmessage databases exist on both ends of the communication channel.

The central message database allows for broader analysis of trends thatmay include: time between sub-processes, variances by customer,variances by order amount, bottlenecks in the process, etc. For example,it would be possible to determine how many orders stood between Orderand Invoice. This may allow for the acceleration of some orders so theycould be booked by quarter close. For example, a vendor bottleneck maybe identified in the course of review of the processes, sub-processesand/or activities. For example, seasonal variations in processes,sub-processes and/or activities may be identified as well.

Of course, some embodiments may create mirror databases and/or generateother databases that can be used by various entities. For example, anenterprise may create a number of central message databases which couldtrack processes, sub-processes and/or activities in whole or part. Thesedatabases could also be combined as desired.

Monitoring message database(s) may be used, in some embodiments, invarious ways, either in addition to or instead of central messagedatabase(s.) For example, a monitoring message database or a centralmessage database may be used to generate messages and feedback to theprocesses, sub-processes, activities and/or applications, as well as tousers and/or administrators (herein generally “users.”) Various messagestransmitted from sub-process applications such as error messages wouldgenerate special monitoring messages which would be added to a messagemonitoring database. Other events, exceptions, triggers and thresholds,could be tracked as well in various embodiments and be used to signalconditions, problems, etc. by various methods such as “flagged” orspecially designated messages or other indicators.

Access to the database(s) is, in the preferred embodiments, on a securedor authorized basis, with different users obtaining different levels ofaccess to the data in the database.

FIG. 3 shows a screen shot of an example of a preferred embodiment whereaccess was made available to a customer over a corporate extranet. Thescreen shot is of a report, generated through an XML link to the centralmessage database, of that particular customer's orders. In the preferredembodiments, the customer has the option to “drill down” through thisscreen to other screens for further detail. So, for example, FIG. 4shows a result of one such operation, where the customer had drilleddown from the screen of FIG. 3. Of course, these records may varydepending on the status of the transaction, that is, whether thetransaction is in the middle of the process, at the beginning of theprocess, etc. Furthermore, other reporting options may be seen dependingon the embodiments. Additionally, in some embodiments the user may havethe option to drill down further into or past these levels if desired.

The preferred embodiments of the present invention also provide asimulation module for business processes. The simulation module makespossible simulation of new processes, their sub-processes and theactivities that make up the sub-processes. This provides the enterpriseor other user with the opportunity to assemble, test, adjust, andsimulate processes before they are integrated into the enterprise.

The simulation module of the preferred embodiments provides the abilityto assemble simulated processes in two primary ways. The first primaryway is through provision of a toolkit or palette of predeterminedsub-processes to the user. The user can then choose from that palette ofsub-processes to form a process for an organization, which is then usedin the simulation as is explained in further detail below.

The second primary method of assembling processes is to provide the userwith activities, which are the most granular construct of a sub-process.Additionally, more sophisticated users will be given the opportunity toassemble their own activities. Either or both options of this secondprimary method can be offered in various embodiments. Additionally, thefirst and second primary methods can be combined in certain embodimentsas well.

The preferred embodiments permit use of discrete activities amongsub-processes, perhaps in an object oriented format, in order to savetime and increase productivity. These activities can then be connectedto form one or more sub-processes, which in turn can be connected toform one or more processes. The ability to create additionalsub-processes would allow for the company to add their uniquesub-processes to the palette.

It should be noted that in other embodiments, the simulation module maybe constructed in other ways. For example, preconfigured,industry-specific processes may be supplied that can be altered and/orprovided with enterprise specifics.

The simulation model is contained, in the preferred embodiments, on acorporate intranet or extranet. The underlying assumption of thesimulation model in the preferred embodiments is that the completion ofeach sub-process will generate a message. So, for example, if a processsuch as that of FIG. 1 is simulated, the completion of the firstsub-process will generate a message to be sent to the next sub-process,the completion of the next sub-process will generate a message that willbe sent to the next sub-process, and so on.

FIG. 5 shows a process development environment screen for an exampleprocess called “Order” of the simulation module. Sub-processes Inquiry,Quote, Agreement, Order, Schedule, Manufacture, Ship and Invoice havebeen joined together to comprise this process. The sub-processes, inthis example, are predetermined and their activities are predetermined.The input and output queue names are identified where appropriate. Forexample, the output queue name in the Inquiry sub-process is INQUIRY_(—) OUT. That output queue then feeds data into the input queue of theQuote sub-process. (These are analogous to Path A in FIG. 1.) The basedelay provides the initial time of a sub-process. For example, the basedelay for the Quote Sub-process is 1 or a time increment of 1. Incontrast the Manufacture Sub-process base delay is 48, so that the timeincrement for the Manufacture Sub-process is 48. The Current Variationshows the Increase/Decrease Variation set by the slider, permitting anincrease or decrease in the latency per process and thus permits theuser to see the downstream effect of altering each sub-process time.(Other embodiments may use different apparatus and methods as known inthe art to vary the latency of the sub-process.) In this example, thetotal time of the process is obtained by adding each base delay of eachsub-process, however, each sub-process may not affect the other in ageometric or logarithmic progression. For example, varying the basedelay by one time increment of the Quote sub-process may not lead to anexact one time increment variation in the Scheduling sub-process.

FIGS. 6 through 9 are examples of tools that are used in this embodimentto construct sub-process modules such as those used in FIG. 5. Forexample, FIG. 6 shows the properties of the Agreement sub-processmodule, which are the process, the sub-process and the application usedin the sub-process. The process and sub-process are predetermined inthis module. The user has the option of setting the applicationalternative of the sub-process to one or more predeterminedalternatives. These alternatives would be used, for example, when a newapplication might be used to provide output from the sub-process.

FIG. 7 shows a message queue construction tool for the sub-processidentified in FIG. 6. This tool, which may be another option combinedwith the process tool of FIG. 6 or some other tool in variousembodiments, or may be stand-alone in other embodiments, provides theability to select a queue manager (a process that manages differentmessage queues in various machines or applications), input queue andoutput queue for the particular sub-process being simulated. Each ofthese options, queue manager, input queue and output queue, can bechanged by using the arrows to access a drop-down menu of predeterminedalternatives. Once the alternatives are chosen, the module can be saved.Of course, in other embodiments non-predetermined alternatives may beused.

FIG. 8 shows an application construction tool, which can be used toselect the applications used on either end of the queue or path. Here,there are two separate targets, one external, with a single monitoringmessage being sent to a central message database, before the sourcemessage is split and sent to both target applications. FIG. 9 shows theparticular data fields or points that may be captured in the monitoringmessage. These are selected by highlighting the preferred fields in thisembodiment.

Other alternatives are possible for other embodiments of the simulationmodule. For example, the embodiments discussed above have somealternatives as predetermined, which makes the construction ofsub-process modules more convenient. In other embodimentsnon-predetermined alternatives may be used. Moreover, any desiredprocesses that are not defined in predetermined modules can be developedand made available to the user. For example, a tool such as that shownin FIG. 10 provides the ability to alter the process, the sub-process,and the application, by using the arrows to access a drop-down menu ofpredetermined alternatives, thus facilitating creation of new processes,sub-processes and/or activities. Other embodiments may use an “openended” format to allow the creation of new processes and sub-processesand/or activities.

The simulation module is, in the preferred embodiments, eitherstand-alone or contained as part of a monitoring apparatus and/or systemas had been described above. If the latter, then “real-time” data andprocesses, sub-processes and activities can be used in the simulationapparatus and/or process. The simulator module permits processes andsub-processes to be defined, simulated, and refined before modifyingexistent systems or implementing new systems.

The above description and the views and material depicted by the figuresare for purposes of illustration only and are not intended to be, andshould not be construed as, limitations on the invention.

Moreover, certain modifications or alternatives may suggest themselvesto those skilled in the art upon reading of this specification, all ofwhich are intended to be within the spirit and scope of the presentinvention as defined in the attached claims.

TABLE 1 PATH FIELDS IDENTIFIERS B PROCESS IDENTIFIER Order to cash,SUBPROCESS IDENTIFIER quote, CUSTOMER NUMBER custno, MATTER NUMBERmatno, QUOTE NUMBER quote num, QUANTITY qty, PRICE price, AMOUNT amt,DATE date, TIME time C PROCESS IDENTIFIER Order to cash, SUBPROCESSIDENTIFIER Agreement, CUSTOMER NUMBER custno, MATTER NUMBER matno, QUOTENUMBER quote num, QUANTITY qty, PRICE price, AMOUNT amt, DATE date, TIMEtime D PROCESS IDENTIFIER Order to cash, SUBPROCESS IDENTIFIER order,ORDER NUMBER ordernum, QUOTE NUMBER quote num, CUSTOMER NUMBER custno,MATTER NUMBER matno, QUANTITY qty, PRICE price, AMOUNT amt, DATE date,TIME time E PROCESS IDENTIFIER Order to cash, SUBPROCESS IDENTIFIERschedule, ORDER NUMBER ordernum, QUOTE NUMBER quote num, PRODUCTIONNUMBER production Number, PRODUCTION DATE Production date, PRODUCTIONLOCATION production location, PRODUCTION STATUS production status,CUSTOMER NUMBER custno, MATTER NUMBER matno, QUANTITY qty, PRICE price,AMOUNT amt, DATE date, TIME time F PROCESS IDENTIFIER Order to cash,SUBPROCESS IDENTIFIER mfg, ORDER NUMBER ordernum, QUOTE NUMBER quotenum, PRODUCTION NUMBER production Number, PRODUCTION DATE Productiondate, PRODUCTION LOCATION Production location, PRODUCTION STATUSProduction status, CUSTOMER NUMBER custno, MATTER NUMBER matno, QUANTITYqty, PRICE price, AMOUNT amt, DATE date, TIME time G PROCESS IDENTIFIEROrder to cash, SUBPROCESS IDENTIFIER ship, ORDER NUMBER ordernum, QUOTENUMBER quote num, PRODUCTION NUMBER production Number, PRODUCTION DATEProduction date, PRODUCTION LOCATION production location, PRODUCTIONSTATUS production status, CUSTOMER NUMBER custno, SHIPPING DATE shipdate, MATTER NUMBER matno, QUANTITY qty, PRICE price, AMOUNT amt, DATEdate, TIME time H PROCESS IDENTIFIER Order to cash, SUBPROCESSIDENTIFIER invoice, ORDER NUMBER ordernum, QUOTE NUMBER quote num,CUSTOMER NUMBER custno, SHIPPING DATE ship date, MATTER NUMBER matno,QUANTITY qty, PRICE price, AMOUNT amt, DATE date, TIME time

1.-55. (canceled)
 56. A computerized method for use in an asynchronousmessaging environment, wherein said messaging environment comprises atleast one original message comprised of original message data,comprising: a first process, sub process, application, or activitysending said original message comprised of said original message data toa second process, sub process, application or activity via a messagingbroker, providing a monitoring message, wherein said monitoring messagecomprises a copy of at least some original message data comprising saidoriginal message; and, transmitting said monitoring message to arepository, wherein said original message data comprises the status of aprocess, sub process or activity.
 57. A method as in claim 56 whereinsaid repository is a central message repository.
 58. A method as inclaim 56 wherein said repository is a message monitoring repository. 59.A method as in claim 56 wherein said original message data is providedin data fields.
 60. A method as in claim 59 wherein said data fieldscomprise process identifier information or sub process identifierinformation.
 61. A method as in claim 56 wherein said repository storesat least some original message data.
 62. A method as in claim 56 whereinthe data in said repository may be used to generate messages to one ormore processes, sub processes, activities, applications, users and/oradministrators.
 63. A method as in claim 56 wherein the data in saidrepository may be used to generate feedback to one or more processes,sub-processes, activities, applications, users and/or administrators.64. A method as in claim 56 further comprising generating a monitoringmessage.
 65. A method as in claim 58 further comprising generatingmessages and/or feedback to the group consisting of processes,sub-processes, activities, applications, users and/or administrators.66. A method as in claim 65 wherein said messages comprise errormessages.
 67. A method as in claim 65 wherein said messages compriseevent messages.
 68. A method as in claim 65 wherein said messagescomprise exception messages.
 69. A method as in claim 65 wherein saidmessages comprise trigger messages.
 70. A method as in claim 65 whereinsaid messages comprise threshold messages.
 71. A method as in claim 65wherein said messages comprise flagged indicators.
 72. A method as inclaim 65 wherein said messages comprise specially designated messages.73. A method as in claim 56 further comprising distributing informationregarding the progress of transaction records and/or processes using areal time tool.
 74. A method as in claim 56 wherein said data fields arepath specific data fields.
 75. A method as in claim 56 furthercomprising providing access to said repository.
 76. A method as in claim75 further comprising providing access to a user and/or administrator.77. A method as in claim 56 further comprising reviewing saidrepository.
 78. A method as in claim 56 further comprising providing thestatus of a process, sub process and/or activity.
 79. A method as inclaim 56 further comprising providing access to said repository througha display.
 80. A method as in claim 79 further comprising furthercomprising providing the status of a process, sub process and/oractivity through a display.
 81. A method as in claim 56 whereinproviding a monitoring message, wherein said monitoring messagecomprises a copy of at least some original message data comprising saidoriginal message, further comprises providing said monitoring messagethrough a messaging component.
 82. A method as in claim 56 furthercomprising simulating said method.
 83. A method as in claim 82 furthercomprising simulating said method with real time data, processes, subprocesses and/or activities.
 84. A method as in claim 56 furthercomprising simulating said method prior to implementation.
 85. A methodas in claim 56 further comprising simulating said method prior tointegration into an enterprise.
 86. A computerized method for assemblingand simulating enterprise communications and processes comprising:providing at least two sub processes; and assembling said at least twosub processes into a simulated process wherein a first of the at leasttwo sub processes communicates with a second of said at least two subprocesses by providing a message with output data and said second of atleast two sub processes accepts said message as providing input data.87. A method as in claim 86 further comprising providing said methodwith real time data, processes, sub processes and/or activities.
 88. Amethod as in claim 86 further comprising simulating said method prior toimplementation.
 89. A method as in claim 86 further comprisingsimulating said method prior to integration into an enterprise.
 90. Amethod as in claim 86 further comprising providing said method via adisplay.
 91. A method as in claim 86 further comprising providing saidmethod via a process development environment screen display.
 92. Amethod as in claim 86 wherein said data is provided in a data field. 93.A method as in claim 86 further comprising providing a user with toolsto construct a sub process.
 94. A method as in claim 93 furthercomprising providing a user with said tools through a screen display 95.A method as in claim 93 wherein said tools identify properties of saidsub process.
 96. A method as in claim 95 wherein said propertiescomprise a process, sub process, application, activity, message queueand/or data field.
 97. A method as in claim 86 further comprisingproviding a message queue construction tool.
 98. A method as in claim 97wherein said message queue construction tool provides alternatives forqueue manager, input queue and/or output queue.
 99. A method as in claim95 further comprising providing an application construction tool.
 100. Amethod as in claim 99 wherein said application construction toolprovides one or more applications at either end of a queue or path toreceive said message.
 101. A method as in claim 100 further comprisingproviding a section of particular data fields.
 102. A method as in claim86 further comprising providing activities.
 103. A method as in claim 86further comprising altering an existing process, sub process oractivity.
 104. A method as in claim 86 further comprising altering anexisting process, sub process or activity.
 105. A method as in claim 86wherein said simulation occurs before modifying existent systems orimplementing new systems.
 106. A system for use in a networkedasynchronous messaging environment, wherein said messaging environmentcomprises at least one original message comprised of original messagedata, comprising: a first process, sub process, application, or activityfor sending said original message comprised of said original messagedata to a second process, sub process, application or activity; amessaging broker for transporting said original message between saidfirst and second process, sub process, application, or activity; amonitoring message, wherein said monitoring message comprises a copy ofat least some original message data comprising said original message forsending to a repository for storage of said at least some originalmessage data, wherein said original message data comprises the status ofa process, sub process or activity.
 107. A system as in claim 106further comprising a display for providing the status of a process, subprocess and/or activity.
 108. A system as in claim 106 wherein said atleast some original message data comprises process identifierinformation or sub process identifier information.
 109. A system as inclaim 106 further comprising a message for sending to one or moreprocesses, sub processes, activities, applications, users and/oradministrators.
 110. A system as in claim 106 further comprisingfeedback to one or more processes, sub-processes, activities,applications, users and/or administrators.
 111. A system as in claim 106wherein said original message data is at least partially simulatedoriginal message data.
 112. A computer-readable storage medium storingprogram code for an asynchronous messaging environment, wherein saidmessaging environment comprises at least one original message comprisedof original message data, comprising: a first process, sub process,application, or activity sending said original message comprised of saidoriginal message data to a second process, sub process, application oractivity via a messaging broker, providing a monitoring message, whereinsaid monitoring message comprises a copy of at least some originalmessage data comprising said original message; and, transmitting saidmonitoring message to a repository, wherein said original message datacomprises the status of a process, sub process or activity.
 113. Acomputer-readable storage medium storing program code as in claim 112wherein said repository is a central message repository.
 114. Acomputer-readable storage medium storing program code as in claim 112wherein said repository is a message monitoring repository.
 115. Acomputer-readable storage medium storing program code as in claim 112wherein said repository stores at least some original message data. 116.A computer-readable storage medium storing program code as in claim 112wherein the data in said repository may be used to generate messages toone or more processes, sub processes, activities, applications, usersand/or administrators.
 117. A computer-readable storage medium storingprogram code as in claim 112 wherein the data in said repository may beused to generate feedback to one or more processes, sub-processes,activities, applications, users and/or administrators.
 118. Acomputer-readable storage medium storing program code as in claim 112further comprising generating a monitoring message.
 119. Acomputer-readable storage medium storing program code as in claim 112further comprising reviewing said repository.
 120. A computer-readablestorage medium storing program code as in claim 112 further comprisingproviding the status of a process, sub process and/or activity.
 121. Acomputer-readable storage medium storing program code as in claim 112wherein providing a monitoring message, wherein said monitoring messagecomprises a copy of at least some original message data comprising saidoriginal message, further comprises providing said monitoring messagethrough a messaging component.
 122. A computer-readable storage mediumstoring program code as in claim 112 further comprising simulating saidmethod.
 123. A computer-readable storage medium storing program code asin claim 112 further comprising simulating said method with real timedata, processes, sub processes and/or activities.
 124. Acomputer-readable storage medium storing program code as in claim 112further comprising simulating said method prior to implementation. 125.A computer-readable storage medium storing program code as in claim 112further comprising simulating said method prior to integration into anenterprise.